Appl. No. 10/052,284 

Amdt dated February 19, 2008 

Reply to Office action of October 19, 2007 

REMARKS 

This Amendment is in response to the Final Office Action mailed July 3, 2007. 
Claims 21 and 5 1 have been amended. No claims have been added or cancelled. Thus, 
claims 21-42, 44-61, and 63-70 remain pending. Reconsideration in light of the 
amendments and remarks made herein is respectfully requested. 

Rejection Under 35 U.S.C § 102 

The Examiner rejects claims 21-42, 46-48, 51-61. and 67-70 under 35 U.S.C. § 
102(e) as being anticipated by Zintel (U.S. Patent No. 6,725,281). Applicants respectfully 
disagree. 

Zintel describes a universal plug and play (UPNP) architecture where a user 
interface on board a client device may control host devices, such as VCRs, cameras, 
printers, etc. (Zintel, column 7, lines 44-52; column 48, lines 58-61). The client devices, 
or user control points, include a rehydrator that obtains a description of the protocols which 
are utilized by a controlled device to activate functions of the controlled device (Zintel, 
column 19, line 59 to column 20, line 51 ; Figure 7). When an event occurs at a device, 
software on that device updates a state table of the device and creates a notification 
indicating the update. This update is then propagated to the rest of the plug and play 
devices so that those devices may update their own state tables (Zintel, column 28, lines 
64-67). 
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Claim 21, as amended, recites in part: 

a module for generating at least one high-level event message indicating 
that an event has occurred that is relevant to the media capture device; 

a router on-board the media capture device for determining whether said at 
least one high-level event message is handled locally at the media 
capture device or remotely at the second device; 

a mapper on-board the media capture device for mapping said at least one 
high-level message into at least one lower-level message for controlling 
one or more hardware elements controlled by the second device, the at 
least one lower-level message includes implementation specific 
information for the one or more hardware elements based on the second 
device and the event; 

Applicants respectfully submit that Zintel fails to teach each and every feature as 

claimed in claim 21. 

Zintel describes that a controlled device may respond to discovery requests of 
devices that are new to an existing universal UPNP network, accept controls from a user 
control point, and send events to user control points (Zintel, column 6, lines 48-52). Each 
controlled device includes a server in order to responds to the requests of user control 
points (Zintel, column 10, lines 41-52). Furthermore controlled devices broadcast event 
messages to update all subscripting UPNP devices that an update has occurred, on the 
controlled device (Zintel, column 28, lines 30-37). 

In the passages cited above and relied upon by the Examiner, Zintel describes that a 
controlled device may either respond directly to user control point requests, or broadcast 
device status for a controlled device. Furthermore, Zintel describes that all user control 
points include a rehydrator, which acts as an adaptor for translating messages received 
from a receiving controlled device, or which creates messages formatted so that a 
controlled device may understand it (Zintel, column 20, lines 31-65). The rehydrator is 
described and illustrated as existing within user control points {See Figures 7-10), and not 
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controlled devices. Thus, any events, commands, or activities which are generated by, or 
the result of a response by, controlled devices, are handled at user contr ol points and not at 
the controlled devices . 

Further, prior to a controlled device being subject to commands of a user control, 
point, the controlled device must supply the user control point with a Service Control 
Protocol Definition embedded in a Description Document (Zintel, column 20, lines 17-30). 
The Description Document is provided to each user control point to allow the user control 
point to handle incoming messages from specific controlled devices, as well as to format 
commands for specific controlled devices. 

Applicants, however, claim "a mapper on-board the media capture device for 
mapping said at least one high-level message into at least one lower-level message for 
controlling one or more hardware elements controlled by the second device . . ." Zintel 
describes the exact opposite, as Zintel requires that user control points utilize the 
Description Document to perform message translation and handling at the user control 
point and not the controlled device . Only after the user control point, via the rehydrator 
and the Description Document, translates a message from a controlled device, are hardware 
or user interface elements impacted at the controlled device. The controlled devices 
merely provide the Description Document and notices that conform to the Document to 
control points, for the future use by the control points. Therefore, Zintel fails to teach any 
translation or mapping of commands at a controlled device , and thus fails to teach "a 
mapper on-board the media capture device for mapping said at least one high-level 
message into at least one lower-level message for controlling one or more hardware 
elements controlled by the second device . . as claimed. 
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Zintel further states with reference to the Description Document that: 

In UPnP, this data description takes the form of the Description Document 
226, which contains a Contract 412. The Contract defines network data 
packets 413 (e.g., XML data), request/response patterns, and protocol (e.g., 
GENA, HTTP, SSDP) via which the packets are exchanged. This 
information is sufficient for the Rehydrator to exchange the appropriate 
network data packets to interact with the Controlled Device Service, 
including to invoke commands, query and set properties, and receive and 
respond to events, without download of any executable code to the User 
Control Point 104 device and with a zero installation or configuration 
experience. 

Accordingly, the Rehydrator operates as a univers al proxy object with data- 
driyg n conversion of programmatic interfaces to network data messages. 
F urther, the Rehydrator produces the programmatic interface at the User 
Control Point based solely on an XML data description . This operation 
allows the Rehydrator to produce just-in-time transient interfaces to remote 
device Services without the complexity of code downloads and installation 
or configuration. Upon a later release of the interface by the application, the 
Rehydrator destroys the interface without need to de-install or clean up 
persistent configuration data in a registry or configuration file of the 
operating system or object execution run-time 

(Zintel, column 20, line 40 to 21, line 19 [Emphasis Added]) 

Thus, as recited in Zintel, the conversion of notifications that control and activate hardware 

elements at user control points is performed at the user control point . Further, the 

messages comply with the original controlled device messages format and communications 

protocol that are defined in the Description Document. Only when the original messages 

are processed at the rehydrator, are the appropriate device-specific functions and interface 

elements activated. Thus, even if Zintel were to map high to low level messages at a 

controlled device, the translation to, and inclusion of, device specific functions is explicitly 

performed at controlled devices. Thus, Zintel must also fail to teach "a mapper on-board 

the media capture device for mapping said at least one high-level message into at least one 

lower-level message . . . the at least one lower-level message includes implementation 
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s pecific information for the one or more hardware e lements based on the second device 
and the event ." 

Applicants further claim "a router on-board the media capture device for 

determining w hether said at least one high-level messa g e is hand led locally at the medi a 

rapture device or remotely at the second device ." The Examiner cites Zintel at column 28, 

lines 64-67 as disclosing this limitation. The Examiner further states: 

[A]s seen in Column 6, lines 48-64, the controlled device sends event 
messages to those control points, even if you want to consider these 
message events as being broadcasts, there are still messages being routed 
onto the network. With the idea that the router is not located within the 
controlled device, as seen in Column 6, lines 48-64 and Figure 5, elements 
106, 308, and 234, that within the controlled device (106), the event server 
(308) creates and sends the events to the user control points (104). 

(Office Action, mailed October 19, 2007, pages 1 1-12). 

Applicants respectfully disagree with the Examiner's interpretation of Zintel. The Event 

Subscription Server (308) is described as being responsible for sending updates to 

subscribing user control points in response to events. However, the status updates required 

in the UPNP architecture are automated so that subscribing devices are always provided 

with an updated status for controlled devices {See Zintel, column 17, lines 1-4 stating 

"UPNP rules require every change to an S ST [for a controlled devicel g enerate a 

mrres pondine event to announce the change to the all interest User Control Points"). Thus, 

when an event occurs at a controlled device, the controlled device must send update 

noti fications to user control points because every event requires a notification be broadcast 

to all subscribing devices. Thus, even if such a broadcasted notification is considered 

message routing (Office Action, mailed October 19, 2007, page 11), there is no discretion 

of the controlled device to determine "whether said at least one lower-level message is 
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handled locally at the media capture device or remotely at the second device." Rather, the 
event must be broadcasted to subscripting control points and handled remotely. Thus, 
Zintel must fail to teach "a router on-board the media capture device for determining 
whether said at least one high-level message is handled locally at the media capture device 
or remotely at the second device." 

Therefore, Zintel fails to describe each and every feature as claimed by the 
Applicants in Claim 21 . Applicants respectfully submit that claim 21 is not anticipated by 
Zintel. Claims 22-42, 44, and 46-58 depend on claim 21, and include additional features 
and limitations to those contained in claim 21. Thus, for similar reasons to those discussed 
above with respect to claim 21, claims 22-42, 44, and 46-48 are also not anticipated by 
Zintel. The Applicants respectfully request withdrawal of the rejections of claim 21-42, 44, 
and 46-48 under § 102. 

Claim 51 recites in part: 

a router in the client device to determine whether the at least one high level 

event message should be handled locally at the client device or 

remotely at the host; 
a state transition table to transition the client device to the a new state based 

on the at least one high level event and the client device's present 

state; 

a module to update the client device's current state information; and 
a mapper on the client device for mapping said at least one high-level 

message into at least one lower-level message for controlling one or 
more hardware elements controlled by the host device, the lower- 
level message includes implementation specific information for the 
second device and the event, and for triggering the activation of one 
or more user-perceivable interface elements of the host device. 

As discussed above, with respect to claim 21, Zintel is completely silent as to making any 

determination of mapping or message routing on board a media capture dev ice. Even if the 

system of Zintel were to make a routing determination, the determination is simply not 
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performed "on board" a media capture device. Furthermore, the UPNP architecture of 
Zintel requires that hosts/user control points perform any notification or control translation. 
Because claim 51 claims "a mapper on the client device for mapping said at least one high- 
level message into at least one lower-level message" and "a router in the client device to 
determine whether the at least one high level event message should be handled locally at 
the client device or remotely at the host," claim 51 is not anticipated by Zintel. 
Furthermore, claims 52-61 and 63-65 depend on claim 51, and include additional features 
and limitations. Thus, claims 52-61 and 63-65 are also not anticipated by Zintel. 



Claim 67 recite: 

A method comprising: 

determining one or more user interface elements of a media capture device 
that are supported by a second device and that can cause one or more 
user-perceivable interface elements of the second device to be activated, 
when the media capture device is coupled with the second device; 

receiving a notification at the media capture device, indicating that an event 
has occurred with respect to the media capture device; 

determining, at a router on-board the media capture d evice, whether the 
event should be handled locally at the media capture device or remotely 
at the second device ; 

when the event is to be handled locally, processing the event locally at the 
media capture device; 

transmitting a message to the second device, intended to activate a 
hardware element on the second device; 

activating a hardware element and the one or more user-perceivable 
interface elements on the second device, in response to the message. 

(Emphasis Added) 

As discussed above, with respect to claim 21 and 51, Zintel fails to making any 
determination of message routing on board a media capture device, and teaches the 
opposite as required by UPNP systems. Thus, Zintel fails to teach or suggest "determining, 
atarout gl on-board the media capture device, whether the event should be handled locally 
atthgmgdia ca pture device or remotely at the second device," as claimed in claim 67. 
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Therefore, Zintel fails to anticipate claim 67. Claims 68-70 depend on claim 67, and 
include additional features and limitations. Thus, claims 68-70 are also not anticipated by 
Zintel. 

Therefore, Applicant respectfully requests that the Examiner withdraw the rejection 
of claims 21-42, 46-48, 51-61 and 67-70 under 35 U.S.C. § 102(e) as being anticipated by 
Zintel. 

Rejection Under 35 U.S.C. § 103 

The Examiner rejects claim 49 under 35 U.S.C. § 103(a) as being unpatentable over 
Zintel (U.S. Patent No. 6,725,281) in view of alleged knowledge in the art. Applicants 

respectfully disagree. 

As discussed above with respect to claim 21, Zintel fails to describe or even 
suggest event mapping and message routing on board a media capture device, as claimed. 
The alleged knowledge in the art does not cure this defect of Zintel. Because claim 49, 
which depends from claim 21, and includes additional features and limitations, claim 49 is 
also not anticipated or rendered obvious by Zintel in view of alleged knowledge in the art, 
for at least the same reasons advanced above with respect to claim 21. Applicant 
respectfully requests that the Examiner withdraw the rejection of claim 49 under 35 U.S.C. 
§ 103(a) as being unpatentable over Zintel (U.S. Patent No. 6,725,281). 

The Examiner rejects claims 50 and 66 under 35 U.S.C. § 103(a) as being 
unpatentable over Zintel in view of Amiga (U.S. Patent No. 6,390,371). Applicants 
respectfully disagree. 
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As discussed above, with respect to independent claims 21 and 51, Zintel fails to 
describe or suggest making any mapping and routing decisions, as claimed, on board a 

media capture device. 

Armga describes a user interface generation scheme (Armga, Abstract). To ensure 
that a user interface is properly displayed, an intermediary obtains UI specifications and 
causes a display which is appropriate for the target device (Armga, column 3, line 36 to 
column 4, line 9). However, Amiga's device-specific UI generation fails to describe or 
suggest mapping or routing messages on board a media capture device, as recited, in claims 
21 and 51. Therefore, Zintel and Armga, alone or in combination, fail to render claims 21 
and 51, and thus dependent claims 50 and 66, obvious. 

Applicant respectfully requests that the Examiner withdraw the rejection of claims 
50 and 66 under 35 U.S.C. § 103(a) as being unpatentable over Zintel in view of Armga. 

The Examiner rejects claim 45 under 35 U.S.C. § 103(a) as being unpatentable over 
Zintel in view of Cortjens (U.S. Patent No. 5,526,037). Applicants respectfully disagree. 

As discussed above, with respect to independent claim 21, Zintel fails to describe 
or suggest making any mapping or routing decisions on board a media capture device. 

Cortjens describes generating control signals at local peripheral devices, such as a 
mouse or joystick (Cortjens, column 5, line 59 to column 6, line 2). The peripheral device 
is connected to a controller so that when the controller receives a signal/command from the 
peripheral device, the controller performs a signal conversion before sending the signal to a 
local or remote system (Cortjens, column 5, lines 55-59; column 8, lines 37-39). Thus, 
Cortjens describes a host or server device that performs signal routing, which is separate 
and distinct from the peripheral device that generates control signals. In Cortjens, the 
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peripheral devices are a mouse, joystick, etc. and the peripheral devices are not taught as 
performing any routing functions. Thus, Cortjens also fails to describe or suggest mapping 
and routing messages on board a media capture device, as recited in claim 21. Therefore, 
Zintel and Cortjens, alone or in combination, fail to render claim 21, and thus dependent 
claims 45, obvious. 

Applicant respectfully requests that the Examiner withdraw the rejection of claim 
45 under 35 U.S.C. § 103(a) as being unpatentable over Zintel in view of Cortjens. 

Conclusion 

Applicant reserves all rights with respect to the applicability of the doctrine of 
equivalents. Applicant respectfully requests that a timely Notice of Allowance be issued in 
this case. If a telephone interview would expedite the prosecution of this application, the 
Examiner is invited to contact William L. Jaffe at (714) 557-3800. 

Respectfully submitted, 

BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 



Dated: February 19, 2008 
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